General Checklist

• Affected Issues have been mentioned in the Closing issues section
• Documentation has been written/updated
• PR title is ready for inclusion in changelog

Database Migrations

• If your PR contains a database migation, it MUST be the latest in date order alphabetically

Description

Routes defined in the API

This feature adds the ability to add routes to a project, and then associate that route to an environment. This allows users to add and remove routes without needing to modify their .lagoon.yml files.

If a route defined in the API also exists in the .lagoon.yml file, the route in the API will be used, and the one in the .lagoon.yml file will have changes merged on top of the existing configuration (this is handled during the deployment phase). In most cases, the route in the API will have all the required information when sent from the API, which will override whatever was defined in the .lagoon.yml if there is an existing matching route.

To take advantage of routes in the API, a route will need to firstly be created in the project. When creating a route, you can either create it in an attached or unattached state.

If an environment already exists with an appropriate service, you can add the environment and service to the route at creation time, this would be an attached route. You can create a route without having an environment or service defined, this can be useful if an environment doesn't exist yet.

Once a route is added to a project and attached to an environment, a deployment will need to take place to apply the route in the cluster. Without a deployment taking place, the route will not be used.

Advanced features

There are some more advanced features with routes in the API. These are

• Active / Standy
• Additional domains
• Path based routes
• Annotations

Active / Standby

Active / Stanby environments when using routes in the API become significantly easier to use. Prior to routes in the API, the routes used would need to be defined in both environment .lagoon.yml files. This added some complexity to what is otherwise a relatively simple feature.

With routes in the API, if the project is configured to have a standby production environment, when creating a route you can select if the route be created as an active or standby route and assign it to the necessary environment. You don't need to define it in both environments anymore, when deploying the environments, the API knows which routes it needs to deploy with. When the active/standby switch occurs, the routes get moved in the API to reflect the environment they were moved to accordingly.

Additionally, you can add normal routes to your active/standby environments that are not flagged as active or standby, these will remain attached to the environment during a switch. These can be useful for ensuring you have a route that will always point to an intended environment.

If using routes in the API and the active/standby feature, it is recommended that you remove the production_routes configurations for active/standby from your .lagoon.yml files and only define the routes in the API. Using both API and .lagoon.yml routes at the same time could result in unexpected issues.

Additional domains

Additional domains are a way to add more than 1 domain to a route. One way these would be used is if you have a primary domain, eg example.com, you could add www.example.com as an additional domain to the route. In kubernetes, this will result in a single ingress with multiple host entries, and if LetsEncrypt certificates are used, those domains will be on the same certificate.

This has a hard coded limit of 25 additional domains per route, because LetsEncrypt and potentially others may have different limits on how many domains can be in SAN certificate. This just makes sure the certificate generated isn't too large.

Path based routes

Path base routes are the same idea as described in the docs for .lagoon.yml. These are able to be added and removed using the API on a route.

This also has a hard coded limit of 10 path based routes per route. This is just an arbitrary limit, as I'm not sure how well used this feature is generally. Maybe it could be made it configurable per project (only configurable by a platform level role)

Annotations

Annotations are also available in the API, these also function the same way as described in the docs. The same restrictions apply.

This also has a hard coded limit of 10 annotations per route. This is just an arbitrary limit, as I'm not sure how well used this feature is generally. Maybe it could be made it configurable per project (only configurable by a platform level role)

Usage

The following describes some basic usage of the routes endpoints, the Lagoon UI will support managing routes, but more advanced options may not be immediately available in the UI.

Creating a Route

When creating a route, you can add it directly to an environment, here is an example of creating a generic route on an environment named main pointing to an nginx service. There defaults for fields like tlsAcme and insecure if they aren't provided on creation time.

mutation {
    addRouteToProject(input:{
        domain: "domain.example.com"
        project: "lagoon-demo"
        environment: "main"
        service: "nginx"
    }){
        id
        domain
        source
        service
        tlsAcme
        insecure
        project {
        	name
        }
        environment{
        	name
        }
    }
}

This returns the created object, and you can see the defaults for tlsAcme and insecure here.

{
	"addRouteToProject": {
		"domain": "domain.example.com",
		"environment": {
			"name": "main"
		},
		"id": 6,
		"insecure": "Redirect",
		"project": {
			"name": "lagoon-demo"
		},
		"service": "nginx",
		"source": "API",
		"tlsAcme": true
	}
}

Updating a route

To change fields on a route, you can update them using the following mutation. In this example, setting tlsAcme to false and disabling https redirects.

mutation {
    updateRouteOnProject(input:{
        domain: "domain.example.com"
        project: "lagoon-demo"
        patch: {
          tlsAcme: false
          insecure: Allow
        }
    }){
        id
        domain
        source
        service
        tlsAcme
        insecure
        project {
        	name
        }
        environment{
        	name
        }
    }
}

And the return we can see those changes are made.

{
	"updateRouteOnProject": {
		"domain": "domain.example.com",
		"environment": {
			"name": "main"
		},
		"id": 6,
		"insecure": "Allow",
		"project": {
			"name": "lagoon-demo"
		},
		"service": "nginx",
		"source": "API",
		"tlsAcme": false
	}
}

Deleting a route

To delete a route, you need the route ID. Then run this mutation

mutation {
    deleteRoute(input:{id: 1})
}

Changing which environment a route is attached to

Its possible to move a route from one environment to another. First you have to remove it from the current environment using removeRouteFromEnvironment like so

mutation {
    removeRouteFromEnvironment(input:{
        domain: "domain.example.com"
        environment: "main"
        project: "lagoon-demo"
    }){
        id
        project{
        	name
        }
        environment{
        	name
        }
    }
}

This will remove the route association from the main environment, and the route will now be in an unattached state.

{
	"removeRouteFromEnvironment": {
		"environment": null,
		"id": 6,
		"project": {
			"name": "lagoon-demo"
		}
	}
}

A deployment of the main environment will need to be performed now to ensure it is removed from the environment before it is added to the other environment.

Once the deployment of the environment is done, you can attach the route to the correct environment using addOrUpdateRouteOnEnvironment like so

mutation {
    addOrUpdateRouteOnEnvironment(input:{
        domain: "domain.example.com"
        service: "nginx"
        environment: "dev"
        project: "lagoon-demo"
    }){
        id
        project{
        	name
        }
        environment{
        	name
        }
    }
}

This route is now attached to the dev environment

{
	"addOrUpdateRouteOnEnvironment": {
		"environment": {
			"name": "dev"
		},
		"id": 6,
		"project": {
			"name": "lagoon-demo"
		}
	}
}

A deployment of the dev environment will need to be performed for the route to be created in the environment.

Autogenerated Routes

By default, autogenerated route configuration on projects and environments is not used. This configuration is only configurable in the .lagoon.yml file. However, as soon as autogenerated route configuration is updated on a project or environment in the API, the autogenerated route config in the .lagoon.yml file is ignored.

Disable autogenerated routes for the project

If you want to disable all autogenerated routes for a project, updating the autogenerated route configuration on a

mutation {
    updateAutogeneratedRouteConfigOnProject(
    	input: {
        project: "lagoon-demo"
        patch: {
        	enabled: false
        }
      }
    ) {
      enabled
    }
}

And we can see that the enabled state is now false.

{
	"updateAutogeneratedRouteConfigOnProject": {
		"enabled": false
	}
}

If you want to then enable them for a specific environment, you update the autogenerated route configuration for that environment to override the project settings

mutation {
    updateAutogeneratedRouteConfigOnEnvironment(
    	input: {
        project: "lagoon-demo"
        environment: "main"
        patch: {
        	enabled: true
        }
      }
    ) {
      enabled
    }
}

and we can see the main environment has autogenerated routes enabled

{
	"updateAutogeneratedRouteConfigOnEnvironment": {
		"enabled": true
	}
}

Other

Limits

There are no limits to how many routes can be added per project, maybe there should be?

Autogenerated and Lagoon YAML routes

Phase 2 support for routes in the API would be updating remote-controller and build-deploy-tool to support sending the non-API created routes back to the API to be visualised, then we can look at deprecating the route and routes fields on an environment for apiRoutes directly.

Before/After merge

• revert Makefile overrides for BUILD_DEPLOY_IMAGE_TAG for feat: support for api routes build-deploy-tool#464